% !TEX root = main.tex

\subsection{MDS Methodologies using UML Profiles}
\label{sec:umlprofile}

\begin{figure}[t]
\begin{minipage}[b]{0.45\linewidth}
\centering
\includegraphics[width=\textwidth]{./figures/UMLsec}
\caption{Synthesis of UMLsec}
\label{fig:UMLsec}
\end{minipage}
\hspace{0.5cm}
\begin{minipage}[b]{0.45\linewidth}
\centering
\includegraphics[width=\textwidth]{./figures/secureUML}
\caption{Synthesis of secureUML}
\label{fig:secureUML}
\end{minipage}
\end{figure}

%\begin{figure}[t]
%	\centering
%	\includegraphics[width=0.6\textwidth]{./figures/UMLsec}
%	\caption{Synthesis of UMLsec}
%	\label{fig:UMLsec}
%\end{figure}
%
%\begin{figure}[tb]
%	\centering
%	\includegraphics[width=0.6\textwidth]{./figures/secureUML}
%	\caption{Synthesis of secureUML}
%	\label{fig:secureUML}
%\end{figure}

%\begin{figure}[t]
%	\centering
%	\includegraphics[width=0.45\textwidth]{./figures/SECTET}
%	\caption{Synthesis of SECTET}
%	\label{fig:SECTET}
%\end{figure}


Historically, the first emerged \mds methodologies are using \UML profiles to model both business and security concerns. 
These approaches mostly differ in their profiles used.


% UMLsec
\smallskip\noindent \textbf{UMLsec}\\
\indent \textsc{Security Concerns.} 
J\"urjens proposed \emph{UMLsec} \cite{springerlink:10.1007/3-540-45314-8-14,springerlink:10.1007/11804192-4},
an annotated \UML model for security modeling and analysis. In \emph{UMLsec}, security concerns are system integrity, confidentiality, \etc. 
For example if we consider mobile systems, the security requirement \emph{trusted communication} means the system is resilient regarding various threats of untrusted channels, \eg package lost, data infection, \etc.

\textsc{Modeling \& Analysis.} 
\emph{UMLsec} considers a \UML extension to develop secure systems. 
This proposal uses the majority of \UML diagrams to model security aspects, mainly those that refer to confidentiality and integrity. 
For example, State Diagrams model, the dynamic behavior of objects, and Sequence Diagrams are used to model protocols. 
Deployment Diagrams are also used to model links between components across servers.
This methodology also incorporates the translation of \emph{UMLsec} models defined for the introduction of patterns into the design process.
The security of a subsystem specification is analyzed by modeling the behaviors of the potential attacker, hence, specific types of attackers, that may attack different parts of the system in a specific way.
These attackers are modeled separately as independent \emph{Adversary Machines}.
Model composition is enabled by means of a mapping, which J\"urjens calls
\emph{renaming}. Renaming associates an \emph{Adversary Machine} with the system's
behavioral model by mapping the \textit{stereotypes} with \textit{tags} and
\textit{constraints}. The composed model is called \emph{Concretized Model} in \emph{UMLsec}.

\emph{UMLsec} allows performing security analysis on the
enforcement infrastructure. The \emph{Control Flow Graph} generated from the concretized
model is compiled to first-order logic axioms which can be verified by the
theorem prover included in the toolset.

\textsc{Transformations.}
\emph{UMLsec} produces the infrastructure \emph{Control Flow Graph} by transforming from the concretized model, via a tool called \emph{aiCall}.

\textsc{Traceability.}
\emph{UMLsec} models security concerns as \emph{Adversary Machines}, 
so that threat risks are analyzed by reasoning on potential attacks from those adversaries.
In order to perform such reasoning a Prolog-based tool automatically
generates an \emph{attack sequence} attempting to violate the security
requirement. The attack can then be examined to determine and remove the
weakness of system. This mechanism allows traceability of \emph{UMLsec}.

The synthesis of \emph{UMLsec} according to the Y-Model is shown in \fig \ref{fig:UMLsec}.

% secureUML
\smallskip\noindent \textbf{secureUML}\\
\indent \textsc{Security Concerns.} 
Basin \etal have proposed  \emph{secureUML} \cite{Basin:2011:DMS:1998441.1998443,Basin:2003:MDS:775412.775425,Basin:2006:MDS:1125808.1125810}, a \UML profile for security engineering.
\emph{secureUML} is designed to model and analyze \rbac (Role-Based Access Control). 

\textsc{Modeling \& Analysis.}
\emph{secureUML}, derived from \mof(Meta-Object Facility), consists of:
\begin{itemize}
	\item A \emph{security modeling language}, \ie \emph{secureUML}, for expressing
	security policies (\rbac);
	\item A \emph{system design modeling language}, namely \emph{componentUML} or
	\emph{controllerUML}, for constructing design models against concrete
	scenarios;
	\item A \emph{dialect} provides a bridge by defining the connection points for
	integrating security models and system models.
\end{itemize}
Both \emph{secureUML} or system design modeling languages incorporate an
explicit \emph{abstract syntax} which defines the language primitives used to
build models and a \emph{concrete syntax} which is the notation defines
representation of these primitives.
The \emph{dialect} is a mapping between the abstract syntaxes of system
design modeling language and \emph{secureUML}. It uses sub-typing to classify
construct elements of the \rbac models expressed in \emph{secureUML} as
belonging to subtypes in business models expressed in the system design modeling
languages. As an example, it connects elements in the system design model
representing actions and resources to their corresponding elements in the
security model.

The \rbac policy verification can be performed by queries of \textsc{Ocl} (Object Constraint
Language) constraints defined on the composed model \cite{Basin:2009:AAS:1512996.1513226}. 

\textsc{Transformations.}
The composed model can be amenably transformed basic system code or infrastructure, \ie Enterprise JavaBeans (EJB) or or alternatively Microsoft Enterprise Services (.NET).

\textsc{Traceability.}
There exists no clearly developed mechanism for traceability.

The synthesis of \emph{secureUML} according to the Y-Model is shown in \fig \ref{fig:secureUML}.

% SECTET
\begin{figure}[t]
	\centering
	\includegraphics[width=0.45\textwidth]{./figures/SECTET}
	\caption{Synthesis of SECTET}
	\label{fig:SECTET}
\end{figure}

\smallskip\noindent \textbf{SECTET}\\
\indent \textsc{Security Concerns.} 
Breu \etal have proposed \emph{SECTET} \cite{mdse-breu-jos-2007,10.1007/s10009-007-0045-y},
a framework based on a \UML profile for business and security modeling and analysis.
\emph{SECTET} is mainly designed to deal with access control.

\textsc{Modeling \& Analysis.}
The \emph{SECTET} framework consists of a modeling
component \emph{SECTET-UML} and an Object Constraint Language (\textsc{Ocl}) style
predicative language called \emph{SECTET-PL}. The \UML profile
(\emph{SECTET-UML}) is used to model business requirements and static security
requirements, such as roles and their hierarchies. Dynamic security requirements
are defined as \emph{Type Navigation Expressions} and {Permission Predicates}
expressed in \emph{SECTET-PL}.
The model composition is an annotation process which integrates
\emph{SECTET-UML} models with dynamic security requirement expressions in
\emph{SECTET-PL}, to form a platform independent application model
(\textsc{Pim}), on which platform independent security analysis can be
performed.

Similarly to \emph{secureUML}, in \emph{SECTET} access
control verification may be done on the composed platform independent model by
querying the model using \textsc{Ocl} constraints.


\textsc{Transformations.}
With the necessary platform information, the
platform independent application model (\textsc{Pim}) can be transformed to \textsc{Xacml}
meta-model (M2M). However, \emph{SECTET} conforms weakly to our Y-Model proposal given that, comparing with
\emph{secureUML} where the business and security source code is partially
generated, only \textsc{Xacml} policies can be produced from the model-to-code transformation (M2C).

\textsc{Traceability.}
No traceability is clearly defined and implemented in this methodology.

The synthesis of \emph{SECTET} according to the Y-Model is shown in \fig \ref{fig:SECTET}.






 


